Closed
Bug 553948
Opened 14 years ago
Closed 14 years ago
Crash [@ js_ValueToNumber ] with putImageData
Categories
(Core :: Graphics: Canvas2D, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: humph, Assigned: vlad)
References
()
Details
(Keywords: crash, testcase, Whiteboard: [sg:critical][critsmash:resolved])
Crash Data
Attachments
(1 file)
601 bytes,
text/html
|
Details |
Similar to bug 553938, but not identical: var canvas = document.getElementById('c'); var ctx = canvas.getContext('2d'); var imgData = {data: new Array(10*10*4), width: 10, height: 10}; imgData.data[0] = 0; ctx.putImageData(imgData, 0, 0); Attached a test case (click "Crash Me"). See also http://crash-stats.mozilla.com/report/index/5861cc9c-92a8-43fc-8ffc-f46792100321
Comment 1•14 years ago
|
||
This is the "If imgData.data[0] = 0 had happened" case from bug 553938 comment 3. Fixing that bug should fix this.
Group: core-security
Depends on: 553938
Assignee | ||
Comment 2•14 years ago
|
||
Hmm, I think this is actually the same as bug 543682 -- that array is full of holes, and those are escaping into the normal jsval world. It's fixed on tracemonkey.
Not sure if this is actually exploitable, but once we get 543682 on trunk it won't matter.
Whiteboard: [sg:critical]
Comment 4•14 years ago
|
||
Is this already fixed? A tracemonkey -> mozilla-central merge happened yesterday.
Assignee: nobody → vladimir
Comment 5•14 years ago
|
||
I no longer see a crash with the attached testcase using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a5pre) Gecko/20100419 Minefield/3.7a5pre.
Updated•14 years ago
|
Whiteboard: [sg:critical] → [sg:critical][critsmash:investigating]
Comment 6•14 years ago
|
||
marcia to go back and test on the 3.6.x and 3.5.x branches.
Updated•14 years ago
|
status1.9.1:
--- → ?
status1.9.2:
--- → ?
Updated•14 years ago
|
Summary: Crash [@ js_ValueToNumber ] → Crash [@ js_ValueToNumber ] with putImageData
Comment 7•14 years ago
|
||
No crash using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100503 Firefox/3.6.4 but I get this error in the console: Error: uncaught exception: [Exception... "An invalid or illegal string was specified" code: "12" nsresult: "0x8053000c (NS_ERROR_DOM_SYNTAX_ERR)" location: "https://bug553948.bugzilla.mozilla.org/attachment.cgi?id=433842&t=2egYT1GldS Line: 17"] Also no crash with test case using : Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100315 Firefox/3.5.9 and similar error in console. E
Comment 8•14 years ago
|
||
Resolving for now since we can't reproduce. Feel free to open back up if we see this show up in crash stats.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
Comment 9•14 years ago
|
||
still seen in low volume on major releases with several million users. checking --- js_ValueToNumber 20100510-crashdata.csv found in: 3.6.3 3.5.9 3.6 3.6b4 release total-crashes js_ValueToNumber crashes pct. all 378690 31 8.18612e-05 3.6.3 261522 16 6.11803e-05 3.5.9 33340 9 0.000269946 3.6 14860 5 0.000336474 3.6b4 934 1 0.00107066 os breakdown js_ValueToNumberTotal 31 Win5.1 0.74 Win6.0 0.10 Win6.1 0.13
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
chofmann: are those the same stack as here, with putImageData? That seems pretty high, given the relative paucity of canvas use in the wild.
Comment 11•14 years ago
|
||
ok, I guess comment 9 goes with the real old bug 223166 or other bug(s) that we should open up about js_ValueToNumber crashes. In that sample of 31 reports from yesterday there are no reports with putImageData on the stack. there quite a variation in the stacks with this signature with some of the stacks looking like this 6 times js_ValueToNumber js_Interpret js_Invoke js_InternalInvoke JS_CallFunctionValue nsJSContext::CallEventHandler(nsISupports *,void *,void *,nsIArray *,nsIVariant * *) 3 times js_ValueToNumber js_Interpret js_Invoke js_fun_apply js_Interpret js_Invoke 3 times js_ValueToNumber js_Interpret UserCallWinProcCheckWow js_Interpret js_Interpret StringDuplicateW and then a long tail of different stacks with the top 5 frames each looking different. given the landing mentioned in comment 4, and fixing of bug 550351 its probably time to mark this fixed and maybe open up?
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Comment 12•14 years ago
|
||
bug 565194 for the other stacks.
Updated•14 years ago
|
Whiteboard: [sg:critical][critsmash:investigating] → [sg:critical][critsmash:resolved]
Updated•13 years ago
|
Crash Signature: [@ js_ValueToNumber ]
Updated•9 years ago
|
Group: core-security → core-security-release
Updated•9 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•